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Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Satellite Earth Stations and 
Systems (SES). 

The contents of the present document are subject to continuing work within TC-SES and may change following formal 
TC-SES approval. Should TC-SES modify the contents of the present document it will then be republished by ETSI 
with an identifying change of release date and an increase in version number as follows: 

Version l.m.n 

where: 

• the third digit (n) is incremented when editorial only changes have been incorporated in the specification; 

• the second digit (m) is incremented for all other types of changes, i.e. technical enhancements, corrections, 
updates, etc. 

The present document is part 4, sub-part 6 of a multi-part deliverable covering the GEO-Mobile Radio Interface 
Specifications, as identified below: 

Parti: "General specifications"; 

Part 2: "Service specifications"; 

Part 3: "Network specifications"; 

Part 4: "Radio interface protocol specifications"; 

Sub-part 1: "GMR-2 Mobile Earth Station-Network Interface; General Aspects and Principles; 
GMR-2 04.001"; 

Sub-part 2: "GMR-2 Mobile Earth Station-Network Interface; Channel Structures and Access capabilities; 
GMR-2 04.003"; 

Sub-part 3: "Layer 1 General requirements; GMR-2 04.004"; 

Sub-part 4: "Data Link Layer General Aspects; GMR-2 04.005"; 

Sub-part 5: "GMR-2 Mobile Earth Station - Network Interface; Data Link (DL) layer Specifications; 
GMR-2 04.006"; 

Sub-part 6: "Mobile Radio Interface Signalling Layer 3; General Aspects; GMR-2 04.007"; 

Sub-part 7: "Mobile radio interface Layer 3 Specifications; GMR-2 04.008"; 

Sub-part 8: "Point-to-Point Short Message Services; GMR-2 04.01 1 "; 

Sub-part 9: "Performance requirements on the mobile radio interface; GMR-2 04.013"; 

Sub-part 10: "Rate Adaptation on the Mobile Earth Station (MES) - Gateway System Interface; 
GMR-2 04.021"; 

Sub-part 11: "Call Waiting (CW) and Call Holding (HOLD) Supplementary Services; GMR-2 04.083"; 

Sub-part 12: "Multiparty Supplementary Services (MPTY); GMR-2 04.084"; 

Sub-part 13: "Technical Realisation of the Early Flag Technique; GMR-2 04.201"; 

Sub-part 14: "Call Barring Supplementary Services; GMR-2 02.088"; 
Part 5: "Radio interface physical layer specifications"; 
Part 6: "Speech coding specifications". 
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Introduction 



GMR stands for GEO (Geostationary Earth Orbit) Mobile Radio interface, which is used for mobile satellite services 
(MSS) utilizing geostationary satellite(s). GMR is derived from the terrestrial digital cellular standard GSM and 
supports access to GSM core networks. 

Due to the differences between terrestrial and satellite channels, some modifications to the GSM standard are necessary. 
Some GSM specifications are directly applicable, whereas others are applicable with modifications. Similarly, some 
GSM specifications do not apply, while some GMR specifications have no corresponding GSM specification. 

Since GMR is derived from GSM, the organization of the GMR specifications closely follows that of GSM. The GMR 
numbers have been designed to correspond to the GSM numbering system. All GMR specifications are allocated a 
unique GMR number as follows: 

GMR-n xx.zyy 

where : 

xx.Oyy (z=0) is used for GMR specifications that have a corresponding GSM specification. In this case, the 
numbers xx and yy correspond to the GSM numbering scheme. 

xx.2yy (z=2) is used for GMR specifications that do not correspond to a GSM specification. In this case, only the 
number xx corresponds to the GSM numbering scheme and the number yy is allocated by GMR. 

n denotes the first (n=l) or second (n=2) family of GMR specifications. 

A GMR system is defined by the combination of a family of GMR specifications and GSM specifications as follows: 

• If a GMR specification exists it takes precedence over the corresponding GSM specification (if any). This 
precedence rule applies to any references in the corresponding GSM specifications. 

NOTE: Any references to GSM specifications within the GMR specifications are not subject to this precedence 
rule. For example, a GMR specification may contain specific references to the corresponding GSM 
specification. 

• If a GMR specification does not exist the corresponding GSM specification may or may not apply. The 
applicability of the GSM specifications are defined in GMR-n 01.201. 



ETSI 



GMR-2 04.007 11 ETSI TS 101 377-4-6 V1.1.1 (2001-03) 



1 Scope 



The present document defines the architecture of layer 3 and its sublayers on the GMR-2 Um interface, i.e., the 
interface between the Mobile Earth Station (MES) and the Network. It also defines the basic message format and error 
handling applied by the layer 3 protocols. 

The corresponding protocols are defined elsewhere as follows: 

1) The Radio Resource (RR) management protocol is defined in GMR-2 04.008 [5]; 

2) The Mobility Management (MM) protocol is defined in GMR-2 04.008 [5]; 

3) The Call Control (CC) protocol is defined in GMR-2 04.008 [5]; 

4) The Supplementary Services (SS) protocol is defined in GSM 04.10 [6], GSM 04.8x and GSM 04.9x; 

5) The Short Message Service (SMS) protocol is defined in GSM 04.1 1 [7]. 

The communication between sublayers and adjacent layers and the services provided by the sublayers are distributed by 
use of abstract service primitives. But only externally observable behaviour resulting from the description is 
normatively prescribed by the present document. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, subsequent revisions do apply. 

[1] GMR-2 01.004 (ETSI TS 101 377-1-1): "GEO-Mobile Radio Interface Specifications; 

Part 1 : General specifications; Sub-part 1 : Abbreviations and Acronyms; 
GMR-2 01.004". 

[2] GMR-2 04.001 (ETSI TS 101 377-4-1): "GEO-Mobile Radio Interface Specifications; 

Part 4: Radio interface protocol specifications; Sub-part 1 : GMR-2 Mobile Earth Station-Network 
Interface; General Aspects and Principles; GMR-2 04.001". 

[3] GMR-2 04.005 (ETSI TS 101 377-4-4): "GEO-Mobile Radio Interface Specifications; 

Part 4: Radio interface protocol specifications; Sub-part 4: Data Link Layer General Aspects; 
GMR-2 04.005". 

[4] GMR-2 04.006 (ETSI TS 101 377-4-5): "GEO-Mobile Radio Interface Specifications; 

Part 4: Radio interface protocol specifications; Sub-part 5: GMR-2 Mobile Earth Station - 
Network Interface; Data Link (DL) layer Specifications; GMR-2 04.006". 

[5] GMR-2 04.008 (ETSI TS 101 377-4-7): "GEO-Mobile Radio Interface Specifications; 

Part 4: Radio interface protocol specifications; Sub-part 7: Mobile radio interface Layer 3 
Specifications; GMR-2 04.008". 

[6] GSM 04. 10 (ETSI ETS 300 558 Edition 2): "Digital cellular telecommunications system 

(Phase 2); Mobile radio interface layer 3; Supplementary services specification; General aspects 
(GSM 04.10 version 4.10.1)". 

[7] GSM 04. 1 1 (ETSI ETS 300 559 Edition 4): "Digital cellular telecommunications system 

(Phase 2); Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface 
(GSM 04.1 1 version 4.10.0)". 
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[8] GSM 11.10 (ETSI ETS 300 607): "Digital cellular telecommunications system (Phase 2); 

Mobile Station (MS) conformance specification; Part 1: Conformance specification; 
(GSM 11.10-1 version 4.28.1)". 

[9] ITU-T Recommendation X.200: "Information technology - Open Systems Interconnection 

Basic reference model: The basic model". 



3 Abbreviations 

For the purposes of the present document, the abbreviations listed in GMR-2 01.004 [1] apply. 

4 Introduction 

4.1 General 

The signalling layer 3 provides the functions to establish, maintain and terminate circuit-switched connections across 
the GMR Network and with other networks to which the GMR Network is connected. It provides the necessary 
supporting functions related to supplementary services control and short message service control. Furthermore, it 
includes the functions necessary for mobility management and radio resource management. 

The term "Layer 3" or "Signalling Layer 3" is a general term used to refer to the procedures described in 
GMR-2 04.008 [5], GSM 04.10 [6] and GSM 04.11 [7]. 

The layer 3 is composed of three sublayers comprising: 

1) The Radio Resource Management (RR) functions; 

2) The Mobility Management (MM) functions; and 

3) The Connection Management (CM) functions. 

The Connection Management (CM) sublayer is composed of: 

1) Call Control (CC); 

2) Short Message Service Support (SMS); and 

3) Supplementary Services Support (SS). 

4.2 Objectives 

The objectives of the layer 3 are to provide the means for: 

1) The establishment, operation and release of a dedicated radio channel connection (RR); 

2) Establishment, maintenance and termination of circuit-switched calls (CC); 

3) Supplementary services support (SS); 

4) Short message service support (SMS). 
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4.3 General Characteristics 

4.3.1 Technique of Description 

The signalling layer 3 is described in terms of: 

1) Services provided by the signalling layer 3; 

2) Services assumed from the signalling layer 2; 

3) Functions of the signalling layer 3. 

The functions of the signalling layer 3 are performed by means of the signalling layer 3 protocols between two systems 
which represent the MES side and the Network side of the radio interface as viewed by the MES. The present document 
does not consider the distribution of signalling functions among the different items of network equipment. The 
functions of layer 3 and its supporting lower layers, therefore provide the Mobile Network Signalling (MNS) service to 
the upper layers. 

The service interfaces to the upper layers and to the data link layer 2 are described by means of primitives and 
parameters as recommended in ITU-T Recommendation X.200 [9]. 

The same technique of description is used for the three sublayers. 

4.3.2 Primitives 

The services provided by the various sublayers are described in the present document. The elementary interactions 
among adjacent sublayers are described by primitives. The primitives consist of requests, responses, indications and 
confirmations. The general syntax of a primitive is specified in GMR-2 04.001 [2]. 

4.3.3 Peer-to-Peer Communication 

Exchange of information between two peers of the signalling layer 3 is performed by means of the three sublayer 
protocols. A protocol is a set of rules and formats by which the control information and user data are exchanged 
between the two peers. 

4.3.4 Contents of Signalling Layer 3 Related Technical Specifications 

GMR-2 04.008 [5] specifies the protocols for Call Control, Mobility Management and Radio Resource Management. 
GSM 04.10 [6] specifies the protocols for Supplementary Service Support. 
GSM 04. 1 1 [7] specifies the protocols for Short Message Service Support. 

5 Structure of Signalling Layer 3 Functions 

5.1 Basic Groups of Functions 

Signalling Layer 3 comprises the following groups of signalling functions: 

1) Call Control (CC); 

2) Short Message Service Support (SMS); 

3) Supplementary Services Support (SS); 

4) Mobility Management (MM); 

5) Radio Resource Management (RR). 
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These functional groups are realized by separate protocol control entities. 

In addition, other functions are contained in layer 2 which are related to the transport of messages, e.g., multiplexing 
and splitting. Those functions are defined in the Radio Resource Management and Mobility Management. They have 
the task to route the messages according to the protocol discriminator (PD) and transaction identifier (TI) which are part 
of the message header. In the uplink direction, the MM routing function shall route the messages of the CM entities as 
well as of the MM entity of its own sublayer towards the service access point (SAP) of RR and multiplex them in case 
of parallel transactions. The routing function of Radio Resource Management shall distribute the messages to be sent 
according to their protocol discriminator and the actual channel configuration. In the downlink direction, the messages 
provided at the different service access points of layer 2 are split by the RR routing function according to the protocol 
discriminator. Messages with a PD equal to RR are passed to the RR entity of the sublayer, all other messages are 
provided to the MM sublayer at the service access point RR-SAP. 

The routing function of MM passes the messages according to the protocol discriminator and the transaction identifier 
towards the MM entity or towards the CM entities via the various MM-SAPs. The message header or parts of it are not 
removed by the RR routing function before passing it to the MM sublayer because further routing has to be done by 
MM using the same criteria. This is not in line with the rules of the ISO reference model but it reduces the number of 

message octets. 

5.2 Protocol Architecture 

As shown in figure 5.1, a hierarchy of three sublayers is defined as follows: 

1) The RR sublayer provides services to the MM sublayer and utilizes the services of signalling layer 2; 

2) The MM sublayer provides common services to the entities of the Connection Management (CM) sublayer; 

3) The CM sublayer includes the CC, SS and SMS entities, which are independent entities. 
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Mobile 



Optional 




r 



S-AGCH + S-HPACH 

S-SDCCH 

S-SACCH 

S-FACCH 



=> SAPI 3 



Figure 5.1 : Hierarchy of Sublayers in Signalling Layer 3 
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6 Services Provided by Signalling Layer 3 at the MES 

Side 

The different classes of services provided by signalling layer 3 at the MES side are accessible at the following service 
access points (SAPs): 

1) Registration services at the MMREG-SAP; 

2) Call Control services for normal and emergency calls including call-related Supplementary Services Support 
services at the MNCC-SAP; 

3) Short Message Service Support services at the MNSMS-SAP; 

4) Call-independent Supplementary Services Support services at the MNSS-SAP. 

6.1 Registration Services 

The registration services (location updating, International Mobile Subscriber Identifier (1MS1) attach/detach) are 
provided at the service access point MMREG-SAP. As opposed to all other MN services, these services are provided 
by, and can be directly accessed at, the Mobility Management sublayer. 

6.1 .1 Service State Diagram 

The registration services provided at the service access point MMREG-SAP are illustrated in the state diagrams of 
figure 6.1. 




MMR_NREG_REQ / IND 
MMR_REG_REQ 



MMR_NREG_REQ / 

J — ~- MMR_NREGJREQ / IND 



MMR_REG_REQy MMR_REG_REQ 

MMR_REG_CNF 




MMR_REG_C? 



Figure 6.1 : Registration Services Provided at MMREG-SAP - MES Side 
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6.1.2 Service Primitives 

Table 6.1 : Primitives and Parameters at the MMREG-SAP - MES Side 



PRIMITIVE 


PARAMETER 


REFERENCE 


MMR REQ REQ 


IMSI 


Clause 6.1.2.1 


MMR REG CNF 


- 


Clause 6.1.2.2 


MMR NREG REQ 


- 


Clause 6.1.2.4 


MMR NREG IND 


cause 


Clause 6.1.2.5 



6.1.2.1 MMR_REG_REQ 

Registration request, triggered by activation of the IMSI, e.g., by activation of the MES with inserted Subscriber 
Identity Module (SIM), insertion of the SIM into the activated MES, pressing of a reset button. 

6.1.2.2 MMR_REG_CNF 

Registration confirmation. Indicates to the user that the MES is ready to start a transaction. 

6.1.2.3 [Reserved] 

6.1.2.4 MMR_NREG_REQ 

Request to cancel the registration, stimulated either by removing the SIM or automatically in the power-off phase. 

6.1.2.5 MMR_NREG_IND 

Indication that registration has been canceled or that registration was not possible. Only emergency services are 
available to the user. 

6.2 Call Control Services 

The Call Control services are provided by multiple CC entities at the service access point MNCC-SAP. 
The Call Control service class consists of the following services: 

1) Mobile-originated and Mobile-terminated call establishment for normal calls; 

2) Mobile-originated call establishment for emergency calls; 

3) Call maintaining; 

4) Call termination; 

5) Call-related Supplementary Services Support. 

6.2.1 Service State Diagram 

The Call Control services provided at the service access point MNCC-SAP are illustrated in the state diagram of figures 
6.2.1 and 6.2.2. 
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Except 0, 19 



MNCC- 

FACILITY- 

REQ 



Figure 6.2.1 : Service Graph of Call Control - MES Side 



M NCC_START_DTM F_REQ / CNF 
M NCC_STOP_DTM F_REQ / CNF 
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MNCC MODIFY RSP 



Figure 6.2.2: Service Graph of Call Control Entity - MES Side Active State 
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6.2.2 Service Primitives 



6.2.2.1 



Table 6.2.1 : Primitives and Parameters at MNCC-SAP - MES Side 



PRIMITIVE 


PARAMETER 
(message, info elements of 
message, other parameters) 


REFERENCE 


MNCC SETUP REQ 


SETUP or EMERGENCY SETUP 


Clause 6.2.2.1 


MNCC SETUP IND 


SETUP 


Clause 6.2.2.2 


MNCC SETUP RSP 


CONNECT 


Clause 6.2.2.3 


MNCC SETUP CNF 


CONNECT 


Clause 6.2.2.4 


MNCC SETUP COMPL IND 




Clause 6.2.2.6 


MNCC REJ REQ 


RELEASE COMPLETE 


Clause 6.2.2.7 


MNCC REJ IND 


cause 


Clause 6.2.2.8 


MNCC CALL CONF REQ 


CALL CONFIRMED 


Clause 6.2.2.9 


MNCC CALL PROC IND 


CALL PROCEEDING 


Clause 6.2.2.10 


MNCC PROGRESS IND 


PROGRESS 


Clause 6.2.2.11 


MNCC ALERT REQ 


ALERTING 


Clause 6.2.2.12 


MNCC ALERT IND 


ALERTING 


Clause 6.2.2.13 


MNCC NOTIFY REQ 


NOTIFY 


Clause 6.2.2.14 


MNCC NOTIFY IND 


NOTIFY 


Clause 6.2.2.15 


MNCC DISC REQ 


DISCONNECT 


Clause 6.2.2.16 


MNCC DISC IND 


DISCONNECT 


Clause 6.2.2.17 


MNCC REL REQ 


RELEASE 


Clause 6.2.2.18 


MNCC REL IND 


RELEASE 


Clause 6.2.2.19 


MNCC_REL_CNF 


RELEASE or 
RELEASE COMPLETE 


Clause 6.2.2.20 


MNCC FACILITY REQ 


Facility 


Clause 6.2.2.21 


MNCC FACILITY IND 


Facility 


Clause 6.2.2.22 


MNCC START DTMF REQ 


START DTMF 


Clause 6.2.2.23 


MNCC_START_DTM F_CN F 


START DTMF ACK or 
START DTMF REJ 


Clause 6.2.2.24 


MNCC STOP DTMF REQ 


STOP DTMF 


Clause 6.2.2.25 


MNCC STOP DTMF CNF 


STOP DTMF ACK 


Clause 6.2.2.26 


MNCC MODIFY REQ 


MODIFY 


Clause 6.2.2.27 


MNCC MODIFY IND 


MODIFY 


Clause 6.2.2.28 


MNCC MODIFY RSP 


MODIFY COMPLETE 


Clause 6.2.2.29 


MNCC MODIFY CNF 


MODIFY COMPLETE 


Clause 6.2.2.30 


MNCC SYNC IND 


cause (res. assgn., channel mode 
modify) 


Clause 6.2.2.31 



MNCC SETUP REQ 



Request to send a SETUP or EMERGENCY SETUP message to initiate Mobile-originating establishment of either a 
normal or an emergency call. 

6.2.2.2 MNCC_SETUP_IND 

Receipt of a SETUP message, the Mobile-terminated call establishment has been initiated. 

6.2.2.3 MNCC_SETUP_RSP 

Response to send a CONNECT message to indicate call acceptance by the Mobile-terminated user; call control is 
requested to attach the user connection (if it is not yet attached). 

6.2.2.4 MNCC_SETUP_CNF 

Receipt of a CONNECT message, the Mobile-originated call has been accepted by the remote called user. 
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6.2.2.5 [Reserved] 

6.2.2.6 MNCC_SETUP_COMPL_IND 

Receipt of a CONNECT ACKNOWLEDGE message, the Mobile-terminated call establishment has been completed; 
for a data call, the user is informed that the user connection is attached. 

6.2.2.7 MNCC_REJ_REQ 

Request to reject a Mobile-terminated call if the call is refused or if the call cannot be accepted, e.g., because of missing 
compatibility. 

6.2.2.8 MNCC_REJ_IND 

Indication that the Mobile-originated call has been rejected, e.g., if the MM connection cannot be provided or if the call 
establishment initiation has been rejected by the Network. 

6.2.2.9 MNCC_CALL_CONF_REQ 

Request to confirm a Mobile-terminated call by sending a CALL CONFIRMED message. A bearer capability different 
from that given in MNCC_SETUP_IND may be offered to the remote calling user. 

6.2.2.10 MNCC_CALL_PROC_IND 

Indication to the Mobile-originating user that call establishment has been initiated in the Network and no more call 
establishment information will be accepted by the Network. 

6.2.2.11 MNCC_PROGRESS_IND 

Indication to the Mobile user that a PROGRESS message or a message containing a progress IE (Information Element) 
has been received, e.g., because the call is progressing in the Public Land Mobile Network/Integrated Services Digital 
Network (PLMN/ISDN) environment, or because the call has left the PLMN/ISDN environment, or because in-band 
tones/announcement are available. 

6.2.2.12 MNCC_ALERT_REQ 

Request to send an ALERTING message from the called Mobile user to the remote calling user to indicate that user 
alerting has been initiated. 

6.2.2.13 MNCC_ALERT_IND 

Indication of the receipt of an ALERTING message, alerting call initiator that the call to the remote called user has been 
initiated. 

6.2.2.14 MNCC_NOTIFY_REQ 

Request to send information pertaining to a call, such as user suspended, to the Network by the Mobile user. 

6.2.2.15 MNCC_NOTIFY_IND 

Indication to the Mobile user that information pertaining to a call, such as remote user suspended, has been received 
from the Network. 

6.2.2.16 MNCC_DISC_REQ 

Request to send a DISCONNECT message to the Network in order to clear the end-to-end connection. 
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6.2.2.17 MNCC_DISC_IND 

Indication of the receipt of a DISCONNECT message, by which the Network indicates that the end-to-end connection is 
cleared. 

6.2.2.18 MNCC_REL_REQ 

Request by the Mobile user to send a RELEASE message to inform the Network that the user intends to release the call 
reference and the corresponding MM connection so that the Network can release its MM connection and the 
correspondent call reference. 

6.2.2.19 MNCC_REL_IND 

Indication to the Mobile user (originating or terminating) that a RELEASE message has been received and the Network 
intends to release its MM connection. The Mobile user is requested to release the call reference and the corresponding 
MM connection. 

6.2.2.20 MNCC_REL_CNF 

Confirmation of the Mobile user's request to release the MM connection and call reference in the Network. The Mobile 
user may release the call reference and the corresponding MM connection. 

6.2.2.21 MNCC_FACILITY_REQ 

Request to transport a facility IE for a call-related supplementary service invocation. 

6.2.2.22 MNCC_FACILITY_IND 

Indication that a facility IE for a call-related supplementary service invocation has been received. 

6.2.2.23 MNCC_START_DTMF_REQ 

Request to send a START DTMF message in order to start a DTMF control operation. 

6.2.2.24 MNCC_START_DTMF_CNF 

Confirmation of the receipt of a START DTMF ACKNOWLEDGE or START DTMF REJECT message that the start 
of a DTMF control operation has been acknowledged or rejected. 

6.2.2.25 MNCC_STOP_DTMF_REQ 

Request to send a STOP DTMF message in order to stop a DTMF control operation. 

6.2.2.26 MNCC_STOP_DTMF_CNF 

Confirmation of the receipt of STOP DTMF ACKNOWLEDGE message, the DTMF control operation has been 
stopped. 

6.2.2.27 MNCC_MODIFY_REQ 

Request to start Mobile-originating in-call modification by sending a MODIFY message. 

6.2.2.28 MNCC_MODIFY_IND 

Receipt of a MODIFY message, a Mobile-terminating in-call modification has been initiated. 
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6.2.2.29 MNCC_MODIFY_RSP 

Response to send a MODIFY COMPLETE message to indicate Mobile-terminating in-call modification completion by 
the Mobile user. 

6.2.2.30 MNCC_MODIFY_CNF 

Receipt of a MODIFY COMPLETE message, the Mobile-originating in-call modification has been completed. 

6.2.2.31 MNCC_SYNC_IND 

Indication that a dedicated channel assignment has been performed (res. assgn. = "resource assigned") and/or the 
channel mode has been changed. 

6.3 Call-Independent Supplementary Services Support 
6.3.1 Service State Diagram 

The primitives provided by the call-independent Supplementary Services Support entity and the transitions between 
permitted states are shown in figure 6.3.1. 



MNSS_BEGIN 
REQ / IND 



MNSS_END 
REQ / IND 



MNSS_FACILITY 
REQ / IND 




MNSS_END 
REQ / IND 



STATES: 

IDLE - No SS signaling transaction pending 

CONN - SS signaling transaction established 



Figure 6.3.1 : Service Graph of the Call-Independent Supplementary Services Support Entity - MES 

Side 
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6.3.2 Service Primitives 



Table 6.3.1 : Primitives and Parameters at MNSS-SAP - MES Side 



PRIMITIVES 


PARAMETERS 
(Info elements of message) 


REFERENCE 


MNSS BEGIN REQ 


REGISTER 


Clause 6.3.2.1 


MNSS BEGIN IND 


REGISTER 


Clause 6.3.2.2 


MNSS FACILITY REQ 


FACILITY 


Clause 6.3.2.3 


MNSS FACILITY IND 


FACILITY 


Clause 6.3.2.4 


MNSS END REQ 


REL COMPLETE 


Clause 6.3.2.5 


MNSS END IND 


REL COMPLETE 


Clause 6.3.2.6 



6.3.2.1 



MNSS BEGIN REQ 



Request to send a REGISTER message in order to establish a signalling transaction for the provision of call- 
independent supplementary services. The request for a call independent supplementary service invocation may be 
included. 



6.3.2.2 



MNSS BEGIN IND 



Receipt of a REGISTER message, a signalling transaction is established for the provision of call-independent 
supplementary services after receipt of a REGISTER message. The indication of a supplementary service invocation 
may be included. 

6.3.2.3 MNSS_FACILITY_REQ 

Request to send a FACILITY message for the provision of a call-independent supplementary service invocation. 

6.3.2.4 MNSS_FACILITY_IND 

Receipt of a FACILITY message for a call-independent supplementary service invocation. 

6.3.2.5 MNSS_END_REQ 

Request to send a RELEASE COMPLETE message in order to release the signalling transaction. The request for 
transfer of a supplementary service facility may be included. 



6.3.2.6 



MNSS END IND 



Receipt of a RELEASE COMPLETE message, the singling transaction has been released. The indication of a 
supplementary service facility may be included. 

6.4 Short Message Services Support 

The service provided by the CM sublayer to support the short message service are defined in GSM 04.1 1 [7]. 
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7 Services Provided by Signalling Layer 3 on the 

Network Side 



7.1 



Call Control Services 



The Call Control services are provided by multiple CC entities at the service access point MNCC-SAP. 
The Call Control service class consists of the following services: 

1) Call establishment; 

2) Call maintaining; 

3) Call termination; 

4) Call-related Supplementary Services Support. 

7.1 .1 Service State Diagram 

The Call Control services provided at the service access point MNCC-SAP are illustrated in figures 7.1.1 and 7.1.2. 
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Figure 7.1.1 : Service Graph of Call Control Entity - Network Side 
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Figure 7.1.2: Service Graph of Call Control Entity - Network Side Active State 
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7.1.2 Service Primitives 



Table 7.1.1 : Primitives and Parameters at MNCC-SAP - Network Side 



PRIMITIVE 


PARAMETER 
(message, info elements of 
message, other parameters) 


REFERENCE 


MNCC_SETUP_REQ 


SETUP incl. Mobile ID or 
EMERGENCY SETUP 


Clause 7.1.2.1 


MNCC SETUP IND 


SETUP 


Clause 7.1.2.2 


MNCC SETUP RSP 


CONNECT 


Clause 7.1.2.3 


MNCC SETUP CNF 


CONNECT 


Clause 7.1.2.4 


MNCC SETUP COMPL REQ 


CONNECT ACKNOWLEDGE 


Clause 7.1.2.5 


MNCC SETUP COMPL IND 


CONNECT ACKNOWLEDGE 


Clause 7.1.2.6 


MNCC REJ REQ 


RELEASE COMPLETE 


Clause 7.1.2.7 


MNCC REJ IND 


cause 


Clause 7.1.2.8 


MNCC CALL CONF IND 


CALL CONFIRMED 


Clause 7.1.2.9 


MNCC CALL PROC REQ 


CALL PROCEEDING 


Clause 7.1.2.10 


MNCC PROGRESS REQ 


PROGRESS 


Clause 7.1. 2.11 


MNCC ALERT REQ 


ALERTING 


Clause 7.1.2.12 


MNCC ALERT IND 


ALERTING 


Clause 7.1.2,13 


MNCC NOTIFY REQ 


NOTIFY 


Clause 7.1.2.14 


MNCC NOTIFY IND 


NOTIFY 


Clause 7.1.2.15 


MNCC DISC REQ 


DISCONNECT 


Clause 7.1.2.16 


MNCC DISC IND 


DISCONNECT 


Clause 7.1.2.17 


MNCC_REL_REQ 


RELEASE or 
DISCONNECT 


Clause 7.1.2.18 


MNCC REL IND 


RELEASE 


Clause 7.1.2.19 


MNCC_REL_CNF 


RELEASE or 
RELEASE COMPLETE 


Clause 7.1.2.20 


MNCC FACILITY REQ 


facility 


Clause 7.1.2.21 


MNCC FACILITY IND 


facility 


Clause 7.1.2.22 


MNCC START DTMF IND 


START DTMF 


Clause 7.1.2.23 


MNCC_START_DTMF_RSP 


START DTMF ACK or 
START DTMF REJ 


Clause 7.1.2.24 


MNCC STOP DTMF IND 


STOP DTMF 


Clause 7.1.2.25 


MNCC STOP DTMF RSP 


STOP DTMF ACK 


Clause 7.1.2.26 


MNCC_MODIFY_REQ 


MODIFY or 
BC-parameter 


Clause 7.1.2.27 


MNCC MODIFY IND 


BC-parameter 


Clause 7.1.2.28 


MNCC MODIFY RSP 


MODIFY COMPLETE 


Clause 7.1.2.29 


MNCC MODIFY CNF 


BC-parameter 


Clause 7.1.2.30 



7.1.2.1 MNCC_SETUP_REQ 

Request to send a SETUP message to initiate Mobile-terminated establishment. 

7.1.2.2 MNCC_SETUP_IND 

Receipt of a SETUP or EMERGENCY SETUP message, the Mobile-originating call establishment has been initiated. 

7.1.2.3 MNCC_SETUP_RSP 

Response to send a CONNECT message to indicate call acceptance by the remote user. 

7.1.2.4 MNCC_SETUP_CNF 

Receipt of a CONNECT message, the Mobile-terminated call has been accepted. 
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7.1.2.5 MNCC_SETUP_COMPL_REQ 

Request to send a CONNECT ACKNOWLEDGE message, the Mobile-terminated call establishment has been 
completed. 

7.1.2.6 MNCC_SETUP_COMPL_IND 

Indication of the receipt of a CONNECT ACKNOWLEDGE message, the Mobile-originating call establishment has 
been completed. 

7.1.2.7 MNCC_REJ_REQ 

Reject the Mobile-originated call establishment if the call cannot be accepted. 

7.1.2.8 MNCC_REJ_IND 

A Mobile-terminated call was rejected by the MES, e.g., because of missing compatibility. 

7.1.2.9 MNCC_CALL_CONF_IND 

Receipt of a CALL CONFIRMED message, the Mobile-terminated call has been confirmed. A bearer capability 
different from that given in MNCC_SETUP_REQ may be offered to the remote calling user. 

7.1.2.10 MNCC_CALL_PROC_REQ 

Request to send a CALL PROCEEDING message to indicate to the Mobile-originating user that call establishment has 
been initiated in the Network and no more call establishment information will be accepted. 

7.1.2.11 MNCC_PROGRESS_REQ 

Request to send a PROGRESS message or to piggy-back a progress IE in a suitable CC message in order to give the 
Mobile user information about the call, e.g., that the call is progressing in the PLMN/ISDN environment, or that the call 
has left the PLMN/ISDN environment or that in-band tones/announcement are available. 

7.1.2.12 MNCC_ALERT_REQ 

Request to send an ALERTING message to indicate to the Mobile-originating user that remote-called user alerting has 
been initiated. 

7.1.2.13 MNCC_ALERT_IND 

Receipt of an ALERTING message from the Mobile-terminated user to be sent to the remote-calling user to indicate 
that user alerting has been initiated. 

7.1.2.14 MNCC_NOTIFY_REQ 

Request to send information pertaining to a call, such as user suspended, to the Mobile-originating or the Mobile- 
terminated user. 

7.1.2.15 MNCC_NOTIFY_IND 

Indication from the Mobile-originating or Mobile-terminated user of information pertaining to a call, such as remote 
user suspended. 

7.1.2.16 MNCC_DISC_REQ 

Request to send a DISCONNECT message to the MES in order to clear the end-to-end connection. 
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7.1.2.17 MNCC_DISC_IND 

Receipt of a DISCONNECT message, the MES indicates that the end-to-end connection is cleared. 

7.1.2.18 MNCC_REL_REQ 

Request to send a RELEASE message to inform the MES that the Network intends to release the MM connection and 
the correspondent call reference. 

7.1.2.19 MNCC_REL_IND 

Receipt of a RELEASE message, the User Terminal intends to release its MM connection and call reference. The 
Network is requested to release its call reference and MM connection. 

7.1.2.20 MNCC_REL_CNF 

The RELEASE COMPLETE message has been received, the MM connection in the MES has been released, the 
Network itself shall release its MM connection and the corresponding call reference. 

7.1.2.21 MNCC_FACILITY_REQ 

Request to transport a facility IE for call-related supplementary service invocations. 

7.1.2.22 MNCC_FACILITY_IND 

Indication that a facility IE for call-related supplementary service invocations has been received. 

7.1.2.23 MNCC_START_DTMF_IND 

Indicate the receipt of a START DTMF message in order to start a DTMF control operation. 

7.1.2.24 MNCC_START_DTMF_RSP 

Request to send a START DTMF ACKNOWLEDGE or START DTMF REJECT message in order to acknowledge or 
reject the start of a DTMF control operation. 

7.1.2.25 MNCC_STOP_DTMF_IND 

Indicate the receipt of a STOP DTMF message in order to stop a DTMF control operation. 

7.1.2.26 MNCC_STOP_DTMF_RSP 

Request to send a STOP DTMF ACKNOWLEDGE message in order to acknowledge the completion of a DTMF 
control operation. 

7.1.2.27 MNCC_MODIFY_REQ 

Request to start the Mobile-terminating in-call modification. 

7.1.2.28 MNCC_MODIFY_IND 

Receipt of a MODIFY message, the Mobile-originating in-call modification has been initiated. 

7.1.2.29 MNCC_MODIFY_RSP 

Response to send a MODIFY COMPLETE to indicate to the Mobile user that the Mobile-originating in-call 
modification procedure has been completed. 
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7.1.2.30 MNCC_MODIFY_CNF 

Confirmation that the Mobile-terminating in-call modification has been completed. 

7.2 Call-Independent Supplementary Services Support 
7.2.1 Service State Diagram 

The primitives provided by the call-independent Supplementary Services Support entity and the transitions between 
permitted states are shown in the service graph of figure 7.2.1. 



MNSS_END 
REQ /IND 



MNSS_BEGIN 
REQ/IND 



MNSS_FACILITY 
REQ/IND 




MNSS_END 
REQ/IND 



STATES: 

IDLE - No SS signaling transaction pending 

CONN - SS signaling transaction established 



Figure 7.2.1 : Service Graph of the Call-Independent Supplementary Services Support Entity 

Network Side 



7.2.2 Service Primitives 



Table 7.2.1 : Primitives and Parameters at MNSS-SAP - Network Side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


MNSS BEGIN REQ 


REGISTER 


Clause 7.2.2.1 


MNSS BEGIN IND 


REGISTER 


Clause 7.2.2.2 


MNSS FACILITY REQ 


FACILITY 


Clause 7.2.2.3 


MNSS FACILITY IND 


FACILITY 


Clause 7.2.2.4 


MNSS END REQ 


RELEASE COMPLETE 


Clause 7.2.2.5 


MNSS END IND 


RELEASE COMPLETE 


Clause 7.2.2.6 
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7.2.2.1 MNSS_BEGIN_REQ 

Request to send a REGISTER message in order to establish a signalling transaction for the provision of call- 
independent supplementary services. The request for a supplementary service invocation may be included. 

7.2.2.2 MNSS_BEGIN_IND 

Receipt of a REGISTER message, a signalling transaction is established for the provision of call-independent 
supplementary services. The indication of a supplementary service invocation may be included. 

7.2.2.3 MNSS_FACILITY_REQ 

Request to send a FACILITY message for the provision of a call-independent supplementary service facility. 

7.2.2.4 MNSS_FACILITY_IND 

Receipt of a FACILITY message, a supplementary service facility has been requested. 

7.2.2.5 MNSS_END_REQ 

Request to send a RELEASE COMPLETE message in order to release the signaling transaction by sending a 
RELEASE COMPLETE message. The request for transfer of a supplementary service facility may be included. 

7.2.2.6 MNSS_END_IND 

Indication that the signaling transaction has been released after receipt of a RELEASE COMPLETE message. The 
indication of a supplementary service facility may be included. 

7.3 Short Message Services Support 

The service provided by the CM sublayer to support the short message service are defined in GSM 04.1 1 [7]. 

8 Services Assumed from Signalling Layers 1 and 2 

The services provided by layer 2 are defined in detail in GMR-2 04.005 [3]. A short summary is given below. 

In addition, layer 1 communicates directly with layer 3 for information transfer related to channel management and to 
measurement control. See clause 8.5 below. 

8.1 Priority 

Messages from layer 3 can be sent with: 

1) No priority, i.e., the messages are sent in first-in-first-out order; and 

2) Priority, i.e., a priority message is sent as early as possible by layer 2. 

8.2 Unacknowledged Information Transfer 

Transfer of unacknowledged information using the primitives DL_UNIT_DATA_REQUEST/INDICATION. 
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8.3 Acknowledged Information Transfer 

Transfer of information in multiframe acknowledged mode including the following: 

1) Establishment of data link connection between L3 entities; 

2) Transfer of information in acknowledged mode; 

3) Release of the data link connection. 

The primitives associated with acknowledged information transfer are as follows: 

1) DL_ESTABL1SH_REQUEST/IND1CAT10N/C0NFIRM for establishment of acknowledged mode; 

2) DL_DATA_REQUEST/lNDlCATION for requesting the transmission of a message unit and for indicating the 
reception of a message unit; 

3) DL_SUSPEND_REQUEST/DL_RELEASE_CONFlRM for requesting and confirming the suspension of the 
acknowledged information transfer in the MES upon channel change; 

4) DL_RESUME_REQUEST/DL_ESTABLISH_CONFlRM for requesting and confirming the resumption of the 
acknowledged information transfer in the MES after suspension at channel change; 

5) DL_RELEASE_REQUEST/1ND1CAT10N/C0NF1RM for the termination of acknowledged mode operation; and 

6) DL_RECONNECT_REQUEST for requesting the re-establishment of acknowledged information transfer in the 
MES on the old channel after channel change failure. 

8.4 Random Access 

The transmission/reception of a random access burst is controlled by the primitives 
DL_RANDOM_ACCESS_REQUEST/INDICATION/CONFIRM. 

8.5 Channel Management and Measurements 

The management of channels, i.e., their activation, deactivation, configuration, reconfiguration, through-connection and 
disconnection, is controlled by the RR sublayer in Layer 3. The measurements performed by the physical layer are also 
controlled by the RR sublayer of layer 3, and they are reported to layer 3. 

These functions use primitives MPH_INFORMATION_REQUEST/INDICATION/ CONFIRMATION. 

9 Interlayer Service Interfaces on the MES Side 

9.1 Service provided by the Radio Resource Management 
Entity 

The Radio Resource Management (RR) sublayer provides a service to the Mobility Management entity (MM). 
The RR services are used for: 

1) Establishing control channel connections; 

2) Releasing control channel connections; and 

3) Control data transfer. 

The Radio Resource Management services are represented by the RR-service primitives. 
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RR 
Primitives 
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Network Side 



RR Sublayer 

Peer-to-peer 

protocol 



Figure 9.1.1 : Services Provided at RR-SAP - MES Side 

9.1 .1 Service State Diagram 

The primitives provided by the Radio Resource Management entity and the transition between permitted states are 
shown in figure 9.1.2. 
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RR EST REQ 



RR UNIT DATA IND 




RR ABORT IND 



RR EST CNF 



RR_DATA_REQ/IND 
RR UNIT DATA IND 



RR_SYNC_IND 
ciphering) 
res. assgn.) 
(channel mode modify) 



Figure 9.1.2: Service Graph of the Radio Resource Management - MES Side 



9.1.2 Service Primitives 



Table 9.1.1 : Primitives and Parameters at the RR-SAP - MES Side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


RR_EST_REQ 


Layer 3 message 

Transferred in the SABM frame 


Clause 9.1.2.1 


RR EST IND 


- 


Clause 9.1.2.2 


RR EST CNF 


- 


Clause 9.1.2.3 


RR REL IND 


cause 


Clause 9.1.2.4 


RR_SYNC_IND 


cause (ciphering, res. assgn., 
channel mode modify) 


Clause 9.1.2.5 


RR DATA REQ 


Layer 3 message 


Clause 9.1.2.6 


RR DATA IND 


Layer 3 message 


Clause 9.1.2.7 


RR UNIT DATA IND 


Layer 3 message 


Clause 9.1.2.8 


RR ABORT REQ 


cause 


Clause 9.1.2.9 


RR ABORT IND 


cause 


Clause 9.1.2.10 



9.1.2.1 



RR EST REQ 



Is used by the Mobility Management entity to request establishment of a Mobile originated RR connection. The request 
shall be given only in the IDLE state when the MES listens to the S-HPACH and the previously selected S-BCCH. 



9.1.2.2 



RR EST IND 



Indicates to the Mobility Management entity the establishment of a Mobile-terminated RR connection. By this 
indication, MM is informed that a transparent connection exists and RR is in the dedicated mode. 
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9.1.2.3 RR_EST_CNF 

Is used by RR to indicate the successful completion of a Mobile-originated RR connection establishment. RR 
connection exists and RR is in the dedicated mode. 

9.1.2.4 RR_REL_IND 

Is used by RR to indicate to the Mobility Management entity the release of an RR connection when RR has received a 
CHANNEL RELEASE from the Network and has triggered a normal release of the data link layer. It is also used to 
indicate that a requested RR connection cannot be established. In both cases, RR returns to IDLE mode. 

9.1.2.5 RR_SYNC_IND 

Is used for synchronizing RR and the Mobility Management entity after the establishment of a Mobile-originated or 
Mobile-terminated RR connection. This indication is provided to MM in the following cases: 

1) Ciphering has been started (ciphering); 

2) A traffic channel has been assigned (res. assgn. = "resource assigned"); 

3) The channel mode has been modified (channel mode modify). 

9.1.2.6 RR_DATA_REQ 

Is used by the Mobility Management entity to send control data to its peer entity on the Network side via an existing RR 
connection. 

9.1.2.7 RR_DATA_IND 

Is used by RR to indicate control data, which has been received from its peer entity on the Network side via an existing 
RR connection. 

9.1.2.8 RR_UNIT_DATA_IND 

Is used by RR to provide MM with system info. The system info is received on the current S-BCCH if RR is in the 
IDLE state. If an RR connection has been established, the system info is received on the S-SACCH. 

9.1.2.9 RR_ABORT_REQ 

Request to abort an existing RR connection or an RR connection in progress. The data link, if already established, shall 
be released by a normal release procedure (D1SC/UA) initiated by the MES. This is the only way the MES can trigger 
the release of an RR connection in case of exceptional conditions. The RR returns to the IDLE state. 

9.1.2.10 RR_ABORT_IND 

Indication that the RR connection has been aborted by a lower layer failure and RR has returned to the IDLE state. 

9.2 Services provided by the Mobility Management Entity 

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, the Supplementary 
Services Support (SS) entity and the Short Message Service Support (SMS) entity as illustrated in figure 9.2.1. 

The Mobility Management services primitives are discriminated by the MMCC, MMSS and MMSMS prefix. 
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Figure 9.2.1 : Services Provided at the MMCC-SAP, MMSS-SAP and MMSMS-SAP - MES 

9.2.1 Service State Diagram 

The primitives provided by the Mobility Management entity towards Call Control, call- independent Supplementary 
Services Support and towards Short Message Service Support and the transition between permitted states are Illustrated 
in figure 9.2.2. 
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MMXX UNIT DATA IND 



MMXX EST RE' 



MMXX_REL_ 
REQ /IND 



MMXXJJNIT 
DATA IND 




MMXX EST CNF 



MMCC_SYNC IND 

(res. assgn 

(channel mode modify) 

MMXX_DATA_REQ / IND 

MMXX UNIT DATA REQ /IND 



NOTE 1 : MMCC-primitives only at MMCC-SAP. 

NOTE 2: The prefix MMXX is used for substitution of MMCC, MMSS or MMSMS. 

Figure 9.2.2: Service Graph of the Mobility Management Entity - MES Side 

9.2.2 Service Primitives 

Table 9.2.1 : Primitives and Parameters at MMCC-SAP, MMSS-SAP or MMSMS-SAP - MES Side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


MMXX_EST_REQ' 


Parameters for the appropriate 
CM SERVICE REQUEST (if any) 


Clause 9.2.2.1 


MMXX EST IND' 


First CM message 


Clause 9.2.2.2 


MMXX EST CNF' 


- 


Clause 9.2.2.3 


MMXX REL REQ' 


cause 


Clause 9.2.2.4 


MMXX REL IND' 


cause 


Clause 9.2.2.5 


MMXX DATA REQ' 


Layer 3 message 


Clause 9.2.2.6 


MMXX DATA IND' 


Layer 3 message 


Clause 9.2.2.7 


MMXX UNIT DATA REQ' 


Layer 3 message 


Clause 9.2.2.8 


MMXX UNIT DATA IND' 


Layer 3 message 


Clause 9.2.2.9 


MMCC SYNC IND^ 


cause: res. Assgn. 


Clause 9.2.2.10 


MMXX REEST REQ' 


- 


Clause 9.2.2.11 


MMXX REEST CNF' 


- 


Clause 9.2.2.12 


MMXX ERR IND' 


cause 


Clause 9.2.2.13 


NOTE 1 : MMXX is used as substitution for MMCC, MMSS or MMSMS 
NOTE 2: Only at MMCC-SAP 
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9.2.2.1 MMXX_EST_REQ 

Request used by CC, SS and SMS respectively, to request establishment of an MM connection. Several MM 
connections may be provided in parallel to the requesting entities. The primitive may contain parameters which are 
relevant for the CM SERVICE REQUEST message, e.g., to distinguish a basic call from an emergency call. 

9.2.2.2 MMXX_EST_IND 

Indication to CC, SS or SMS that a Mobile-terminated MM connection has been established and the first message has 
been received from the respective peer entity. Several MM connections may be provided in parallel. If an MM 
connection already exists, a new MM connection using the same RR connection is indicated by this primitive if MM 
detects a message with a new combination of Protocol Discriminator (PD) and Transaction Identifier (TI). 

9.2.2.3 MMXX_EST_CNF 

Successful confirmation of the MM connection establishment by the MM sublayer to be given to the appropriate entity 
which has requested the service. 

9.2.2.4 MMXX_REL_REQ 

Used by CC, SS or SMS, respectively, to request release of the MM connection. The corresponding PD/TI will be 
released and may be used for a new MM connection. 

9.2.2.5 MMXX_REL_IND 

Indication of the release of an existing MM connection or an MM connection in progress. This primitive is used in 
exceptional cases to indicate that the MM connection cannot be established or kept any longer and PD/TI have been 
released. 

9.2.2.6 MMXX_DATA_REQ 

Request used by the CC, SS or SMS entities for acknowledged control data transmission. 

9.2.2.7 MMXX_DATA_IND 

Indication used by MM to transfer the received acknowledged control data to the CC, SS or SMS entities. 

9.2.2.8 MMXX_UNIT_DATA_REQ 

Request used by the CC, SS or SMS entities for unacknowledged control data transmission. 

9.2.2.9 MMXX_UNIT_DATA_IND 

Indication used by MM to transfer the received unacknowledged control data to the CC, SS or SMS entities. 

9.2.2.10 MMCC_SYNC_IND 

Indication that a dedicated channel assignment has been performed and/or the channel mode has been changed (only 
towards the CC entity). 

9.2.2.11 MMXX_REEST_REQ 

Request to establish an MM connection which has been interrupted by a lower layer failure. The interruption must have 
been indicated by MMXX_ERR_IND. 
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9.2.2.12 



MMXX REEST CNF 



Confirmation of the successful re-establishment of the MM connection. The MM connection will continue with PD/TI 
as it had before. 



9.2.2.13 



MMXX ERR IND 



Indication of a lower layer failure interrupting the MM connection. The PD/TI are still kept by MM. In case of parallel 
transactions, this indication is passed to all CM entities for which an MM connection has been established. It is left to 
the decision of the appropriate CM entity to either request the re-establishment of the MM connection by 
MMXX_REEST_REQ or to release it by MMXX_REL_REQ. 



10 Interlayer Service Interfaces on the Network Side 

10.1 Services Provided by the Radio Resource Management 
Entity 

The Radio Resource Management (RR) sublayer provides services to the Mobility Management entity (MM). 
The RR Services are used for: 

1) Establishing control channel connections; 

2) Establishing traffic channel connections; 

3) Ciphering mode indication; 

4) Releasing control channel connections; 

5) Control data transfer. 

The Radio Resource Management services are represented by the RR service primitives. 
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Figure 10.1.1 : Services Provided at RR-SAP - Network Side 



ETSI 



GMR-2 04.007 



39 



ETSI TS 101 377-4-6 V1.1.1 (2001-03) 



10.1.1 Service State Diagram 

The primitives provided by the Radio Resource Management entity and the transition between permitted states are 
shown in figure 10.1.2. 



RRJJNIT_DATA_REQ 
RR REL REQ/IND 



RR EST REQ 



RRJJNIT_ 
DATA_REQ 




RR_REL_REQ / IND 
RR_ABORT_REQ / IND 



RR EST CNF 



RR_DATA_REQ/IND 
RRJJNIT_DATA_REQ / IND 



RR_SYNC_REQ 
ciphering) 
(res. assgn.) 
(channel mode modify) 




RR_DATA_REQ / IND 
RR UNIT REQ/IND 



STATES: 

IDLE -- No dedicated channel established 

CONN PEND - Connecting pending 

DT1 - Data Transfer 1, dedicated Channel established 

DT2 - Data Transfer 2, dedicated channel established, ciphering mode set 

Note: The parameters in RR SYNC_CNF must correspond to the parameter in RR SYNC_REQ. 



Figure 10.1.2: Service Graph of the Radio Resource Management Entity - Network Side 
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10.1.2 Service Primitives 



Table 10.1.1 : Primitives and Parameters at the RR-SAP - Network Side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


RR_EST_REQ 


Parameters for the initial layer 3 
message 


Clause 10.1.2.1 


RR EST IND 


Initial layer 3 message 


Clause 10.1.2.2 


RR EST CNF 


- 


Clause 10.1.2.3 


RR REL REQ 


cause 


Clause 10.1.2.4 


RR REL IND 


cause 


Clause 10.1.2.5 


RR_SYNC_REQ 


cause (resource assign, 
ciphering) 


Clause 10.1.2.6 


RR_SYNC_CNF 


cause (resource assign, 
ciphering) 


Clause 10.1.2.7 


RR DATA REQ 


Layer 3 message 


Clause 10.1.2.8 


RR DATA IND 


Layer 3 message 


Clause 10.1.2.9 


RR UNIT DATA REQ 


Layer 3 message 


Clause 10.1.2.10 


RR UNIT DATA IND 


Layer 3 message 


Clause 10.1.2.11 


RR ABORT REQ 


cause 


Clause 10.1.2.12 


RR ABORT IND 


cause 


Clause 10.1.2.13 



10.1.2.1 RR_EST_REQ 

Request used by the Mobility Management entity to request establishment of control channel connections. 

10.1.2.2 RR_EST_IND 

Indication to the Mobility Management entity that the establishment of control channel connections has been 
completed. 

10.1.2.3 RR_EST_CNF 

Confirmation used by RR to confirm the establishment of a requested control channel connection. 

10.1.2.4 RR_REL_REQ 

Request used by the Mobility Management to release a control channel connection. 

10.1.2.5 RR_REL_IND 

Indication from RR to MM that the main signalling link has been released. 

10.1.2.6 RR_SYNC_REQ 

Request used by the Mobility Management entity for synchronization with the RR protocol. 

10.1.2.7 RR_SYNC_CNF 

Confirmation used by RR that the requested synchronization is completed. 

10.1.2.8 RR_DATA_REQ 

Request used by the Mobility Management entity for acknowledged control data transmission. 

10.1.2.9 RR_DATA_IND 

Indication used by RR to transfer received control data, which should be acknowledged, to the Mobility Management 
entity. 



ETSI 



GMR-2 04.007 



41 



ETSI TS 101 377-4-6 V1.1.1 (2001-03) 



10.1.2.10 RR_UNIT_DATA_REQ 

Request used by the Mobility Management entity for unacknowledged control data transmission. 

10.1.2.11 RR_UNIT_DATA_IND 

Indication used by RR to transfer received control data, which should not be acknowledged, to the Mobility 
Management entity. 

10.1.2.12 RR_ABORT_REQ 

Request to abandon the RR connection. 

10.1.2.13 RR_ABORT_IND 

Indication that a radio link failure has occurred. 

1 0.2 Services provided by the Mobility Management Entity 

The Mobility Management (MM) sublayer provides services to the Call Control (CC) entity, the Supplementary 
Services Support (SS) entity and the Short Message Service Support (SMS) entity as illustrated in figure 10.2.1. 

The Mobility Management services primitives are recognized by the MMCC, MMSS and MMSMS prefix. 
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Figure 10.2.1 : Services provided at MMCC-SAP, MMSS-SAP, MMSMS-SAP - Network Side 

10.2.1 Service State Diagram 

The primitives provided by the Mobility Management entity towards Call Control, Short Message Service Support and 
call-independent Supplementary Services Support as well as the transition between permitted states are illustrated in 
figure 10.2.2. 
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MMXX UNIT DATA REQ 



MMXX REL REQ/IND 



MMXX EST REQ 



MMXXJJNIT 
DATA REQ 




MMXX EST CNF 



MMCC_DATA_REQ / IND 
MMX UNIT DATA REQ/IND 



MMXX_DATA_REQ / IND 
MMXX_UNIT_DATA_REQ / IND 



NOTE1 
NOTE 2 
NOTE 3 



The parameters in MMCC_SYNC_CNF must correspond to the parameter in MMCC_SYNC_REQ. 

MMCC primitives only at MMCC-SAP. 

The prefix MMXX is used for substitution of MMCC, MMSS or MMSMS. 



Figure 10.2.2: Service Graph of the Mobility Management Entity Towards Call Control, Short Message 
Service Support and Call-Independent Supplementary Services Support - Network Side 
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10.2.2 Service Primitives 

Table 10.2.1 : Primitives and Parameters at MMCC-SAP, MMSS-SAP, MMSMS-SAP - Network Side 



PRIMITIVES 


PARAMETERS 


REFERENCE 


MMXX EST REQ' 


Mobile ID 


Clause 10.2.2.1 


MMXX EST IND' 


First CM message 


Clause 10.2.2.2 


MMXX EST CNF' 


- 


Clause 10.2.2.3 


MMXX REL REQ' 


cause 


Clause 10.2.2.4 


MMXX REQ IND' 


cause 


Clause 10.2.2.5 


MMXX DATA REQ' 


Layer 3 message 


Clause 10.2.2.6 


MMXX DATA IND' 


Layer 3 message 


Clause 10.2.2.7 


MMXX UNIT DATA REQ' 


Layer 3 message 


Clause 10.2.2.8 


MMXX UNIT DATA IND' 


Layer 3 message 


Clause 10.2.2.9 


MMCC SYNC REQ^ 


cause (resource assign) 


Clause 10.2.2.10 


MMCC SYNC CNF^ 


cause (resource assign) 


Clause 10.2.2.11 


Note 1 : MMXX is used as substitution for MMCC, MMSS or MMSMS. 
Note 2: Only at MMCC-SAP. 



10.2.2.1 MMXX_EST_REQ 

Request by CC, SS and SMS, respectively, for the establishment of an MM connection. 

10.2.2.2 MMXX_EST_IND 

Indication by the MM sublayer that an MM connection is established. 

10.2.2.3 MMXX_EST_CNF 

Confirmation of the MM connection establishment by the MM sublayer. 

10.2.2.4 MMXX_REL_REQ 

Request by CC, SS or SMS, respectively, for the release of the MM connection. 

10.2.2.5 MMXX_REL_IND 

Indication by the MM sublayer that an MM connection has been released. 

10.2.2.6 MMXX_DATA_REQ 

Request by the CC, SS or SMS entities for acknowledged control data transmission. 

10.2.2.7 MMXX_DATA_IND 

Indication used by MM to transfer the received acknowledged control data to the CC, SS or SMS entities. 

10.2.2.8 MMXX_UNIT_DATA_REQ 

Request used by the CC, SS or SMS entities for unacknowledged control data transmission. 

10.2.2.9 MMXX_UNIT_DATA_IND 

Indication used by MM to transfer the received unacknowledged control data to the CC, SS or SMS entities. 

10.2.2.10 MMCC_SYNC_REQ 

Request used by the CC entity to synchronize with the MM entity (resource assign). 
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10.2.2.11 MMCC_SYNC_CNF 

Confirmation used by the MM to inform the CC entity that synchronization is completed (resource assign). 



1 1 Standard L3 Messages 



In this section, the structure of standard L3 messages and their basic handling are defined. Standard L3 messages are 
used in layer 3 protocols of the Um interface when the relevant protocol specifications, e.g., GMR-2 04.008 [5], define 
so. 

11.1 Components of a Standard L3 Message 

A standard L3 message consists of an imperative part followed by a non-imperative part. Both imperative and non- 
imperative parts are composed of information elements (IEs). 

NOTE: A layer 3 message consists of an integer number of octets, at least one octet, as defined in 
GMR-2 04.006 [4]. 

11.1.1 Format of Information Elements 

An information element (IE) occurring in a standard layer 3 message is known as a standard IE. It consists of a half 
octet or one or more octets. A standard IE may have the following components: 

1) An information element identifier (IEI); 

2) A length indicator (LI); 

3) A value part. 

A standard IE has one of the formats shown in table 11.1.1. 

Table 11.1.1: Formats of Information Elements 



Format 


Meaning 


IEI Present? 


LI Present? 


Value Part 
Present? 


T 


Type only 


yes 


no 


no 


V 


Value only 


no 


no 


yes 


TV 


Type and Value 


yes 


no 


yes 


LV 


Length and Value 


no 


yes 


yes 


TLV 


Type, Length and Value 


yes 


yes 


yes 



11.1.1.1 Information Element Type and Value Part 

Every standard IE has an information element type which determines the values possible for the value part of the IE. 

The value part of a standard IE either consists of a half octet or one or more octets. The value part of a standard IE with 
format LV or TLV may be empty, i.e., consist of zero octets. If it consists of a half octet and has format TV, its IEI 
consists of a half octet. 

The value part of a standard IE may be further structured into fields. 



11.1.1.2 



Length Indicator 



The LI of a standard IE consists of one octet. It contains the binary encoding of the number of octets of the IE occurring 
after the octet containing the LI, with bit 1 as the least significant bit. The length indicator of a standard IE with empty 
value part indicates octets. 



ETSI 



GMR-2 04.007 45 ETSI TS 101 377-4-6 V1.1.1 (2001-03) 

1 1 .1 .1 .3 Information Element Identifier 

The IEI of a standard IE consists of a half octet or one octet. A standard IE with IEI consisting of a half octet has format 
TV, and its value part consists of a half octet. 

11.1.1 .4 Categories of lEs; Order of Occurrence of IEI, LI and Value Part 

A total of five categories of standard information statements are defined as follows: 

1) Information elements of format V or TV with value part consisting of 1/2 octet (type 1); 

2) Information elements of format T with value part consisting of octets (type 2); 

3) Information elements of format V or TV with value part that has fixed length of at least one octet (type 3); 

4) Information elements of format TLV or LV with value part consisting of zero, one or more octets (type 4); 

5) Information elements of format V with value part consisting of zero, one or more octets (type 5). 

Type 1 standard information elements of format V provide the value in bit positions 8, 7, 6, 5 of an octet (see figure 
11.1.1) or bits 4, 3, 2, 1 of an octet (see figure 11.1.2). 



Value Part 



Figure 11.1.1: Type 1 Information Element of Format V 



Value Part 



Figure 11.1.2: Type 1 Information Element of Format V 

Type 1 standard information elements of format TV have an IEI of a half octet length. They provide the IEI in bit 
positions 8, 7, 6, 5 of an octet and the value part in bit positions 4, 3, 2, 1 of the same octet, see figure 11.1.3. 



IEI 


Value Part 



Figure 11.1.3: Type 1 Information Element of Format TV 

A type 2 standard IE has format T. Its IEI consists of one octet, and its value part is empty, see figure 11.1.4. 



8 


7 


6 


5 




4 


3 


2 


1 


IEI 



Figure 11.1.4: Type 2 Information Element 

A type 3 standard information element has format V or TV. If it has format TV, its IEI consists of one octet and 
precedes the value part in the IE. The value part consists of at least one octet. See figures 11.1.5 and 11.1.6. 
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8 7 6 5 4 3 2 1 

| " ~ | octet n 



Value 
Part 



[ 



J octet n + k 



Figure 11.1.5: Type 3 Information Element of Format V (k = 0, 1, 2, ...) 



8 


7 


6 


5 4 


3 


2 


1 


IEI 








Value 
Part 






















I 



octet n 
octet n + 1 



] octet n + k 



Figure 11.1.6: Type 3 Information Element of Format TV (k = 1, 2, ...) 



A type 4 standard information element has format LV or TLV. Its LI precedes the value part, which consists of zero, 
one, or more octets. If present, its IEI has a length of one octet and precedes the LI. See figures 1 1 . 1 .7 and 11.1.8. 
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LI 
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Part 






















I 



octet n 
octet n + 1 



] octet n + k 



Figure 11.1.7: Type 4 Information Element of Format LV (k = 0, 1, 2, ...) 
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Value 
Part 






















I 



octet n 
octet n + 1 
octet n + 2 



] octet n + k 



Figure 11.1.8: Type 4 Information Element of Format TLV (k = 1, 2, ...) 

A type 5 standard information element has format V. Its value part consists of zero, one or more octets. An information 
element of this type can only appear as the last information element in a L3 message for which the layer 3 length is 
either: 

• Indicated by layer 2; 

• Pre-determined (e.g., by the channel used). 

1 1 .2 Imperative Part of a Standard L3 Message 

The imperative part of a standard L3 message is composed of two or more IEs having the format V or LV. 
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11.2.1 Protocol Discriminator 

Bits 1 to 4 of the first octet of a standard L3 message contain the protocol discriminator (PD) information element. It is 
a type 1 IE and has always format V. The PD identifies the L3 protocol to which the standard layer 3 message belongs. 
The correspondence between L3 protocols and PDs is one-to-one. 

The PD can take the values shown in table 1 1.2.1. 

Table 11.2.1: Protocol Discriminator Values 



Bits 


4 


3 


2 


1 












1 


1 


Call Control; Call-related SS messages 







1 





1 


Mobility Management messages 







1 


1 





Radio Resources Management messages 




1 








1 


SMS messages 




1 





1 


1 


Non-call-related SS messages 




1 


1 


1 


1 


Reserved for test procedures described in GSM 1 1 .1 [8] 



If the network receives a standard L3 message with a protocol discriminator different from those specified in table 
1 1.2.1, the network may ignore the message or initiate the channel release procedure defined in GMR-2 04.008 [5]. 

If the MES receives a standard L3 message with a protocol discriminator different from those specified in table 1 1.2.1, 
the MES shall ignore the message. 

11.2.2 Skip Indicator 

Bits 5 to 8 of octet 1 of a standard L3 message may contain the skip indicator IE. The skip indicator IE is a type 1 IE. It 
always has format V in a standard L3 message. The relevant protocol specification may define that a standard L3 
message received with certain values of the skip indicator shall be ignored. 



1 1 .2.3 Transaction Identifier 

Bits 5 to 8 of octet 1 of a standard L3 message may contain the transaction identifier (TI) IE. The TI IE is a type 1 IE 
and always has format V in a standard L3 message. 

The TI IE is coded as shown in figure 1 1 .2. 1 and table 1 1 .2.2. It is composed of the TI value and the TI flag. 

The TI value and the TI flag occupy bits 5-7 and bit 8 of the first octet, respectively. 

TI values are assigned by the side of the interface initiating a transaction. At the beginning of a transaction, a free TI 
value (i.e., a value not yet used for the given PD and with the given originator) is chosen and assigned to this 
transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is 
free and may be reassigned to a later transaction. 

Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite 
ends of the interface. In this case, the TI flag shall avoid ambiguity. The transaction identifier flag can take the values 
"0" or " 1 ." The TI flag is used to identify which end of the radio interface originated a TI. The origination side always 
sets the TI flag to "0." The destination side always sets the TI flag to "1." 

Hence, the TI flag identifies who allocated the TI value for this transaction, and the only purpose of the TI flag is to 
resolve simultaneous attempts to allocate the same TI value. 

The TI may, in future evaluations of the L3 protocols, be extended by using a combination of bits in the TI value field 
that is specified as "reserved for future extension" in table 1 1.2.2. 



8 



1 



TI 
Flag 



TI Value 



octet 1 



Figure 11.2.1: Transaction Identifier 
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Table 11.2.2: Transaction Identifier 



Tl Flag (octet 


1) 




Bit 8 















The messaae is sent from the side that oriainates the Tl 


1 






The message is sent to the side that originates the Tl 


Tl Value 


(octet 1) 




Bit 7 


6 


5 













Tl Value 








1 


1 





1 





2 





1 


1 


3 


1 








4 


1 





1 


5 


1 


1 





6 


1 


1 


1 


Reserved for future extension 



1 1 .2.4 Message Type 



In every standard L3 message, the third IE of the imperative part is the message type IE which is contained in octet 2 of 
the message. 

When a standard L3 message is received that is too short to contain a complete message type information element, that 
message shall be ignored. 

The message type IE is coded as shown in figure 1 1 .2.2. 

Bit 8 is encoded as "0," and value "1" is reserved for possible future use as an extension bit. A protocol entity receiving 
a standard L3 message containing a message type IE with bit 8 encoded as " 1 " shall treat the message type as "not 
defined" for the PD. 

The MM messages and the CM messages using SAPI=0 sent from the User Terminal to the network specify the send 
sequence number N(SD) in bit 7. At the time when such a message is designated for transmission, the value of N(SD) 
for the message to be transferred is set equal to the value of the send state variable. 

In all other standard layer 3 messages, bit 7 is set to "0" by the sending side. The receiving side shall ignore such 
messages if bit 7 is set to "1." 



8 


7 


6 


5 


4 3 


2 


1 





N(SD) 


Message Type 



octet 1 



Figure 11.2.2: Message Type Information Element 

The message type determines the function of a message within a protocol in a given direction. The meaning of the 
message type is therefore dependent on the protocol (the same value may have different meanings in different 
protocols) and direction (the same value may have different meanings, in the same protocol, when sent from the User 
Terminal to the Network and when sent from the Network to the User Terminal). 

The reaction of a protocol entity receiving a message with message type not defined for the PD in that direction is 
defined in the relevant protocol specification. 
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1 1 .2.5 Further Information Elements of the Imperative Part 

The message type IE of a standard L3 message may be followed by further IEs having the format V or LV as defined in 
the relevant protocol specification. 

If a standard L3 message is received that is too short to contain the complete imperative part as specified in the relevant 
protocol specification, an imperative message part error is diagnosed. (The same error may be diagnosed at detection of 
certain contents of the imperative part of a message. This is defined in the relevant protocol specification.) The 
treatment of an imperative message part error is defined in the relevant protocol specification. 

1 1 .3 Non-Imperative Part of a Standard L3 Message 

The imperative part of a standard L3 message is followed by the (possibly empty) non-imperative part. The relevant 
protocol specification defines where the imperative part of a standard L3 message ends. The non-imperative part of a 
standard L3 message is composed of (zero, one or several) IEs having the format T, TV or TLV. The receiver of a 
standard L3 message shall be prepared for the non-imperative part of the message to contain IEs that are not specified in 
the relevant protocol specification. The receiver will assume that the first octet of such IEs contains the IEI. 

An IEI may be known in a message or unknown in a message. Whether it is known or unknown in the message is 
defined in the relevant protocol specification. 

An IEI that is known in a message designates the IE type of the IE the first part of which the IEI is. Which IE type it 
designates is specified in the relevant protocol specification. Within a message, different lEls may designate the same IE 
type if that is defined in the relevant protocol specification. 

Whether the second part of an IE with IEI known in a message is the length or not (in other words, whether the IEI is 
the first part of an IE formatted as TLV or not) is specified in the relevant protocol specification. 

The relevant protocol specification defines which category and format of an IE the receiving side shall assume if the IE 
occurs in the non-imperative part of a received standard L3 message with IEI unknown in the message. 

A message may contain two or more IEs with equal IEI. 

1 1 .4 Presence Requirements of Information Elements 

The relevant protocol specification may define three different presence requirements (M, C or O) for an IE within a 
given message as shown below. 

M ("Mandatory") means that the IE shall be included by the sending side and that the receiver diagnoses a missing 
mandatory IEI error when detecting that the IE is not present. An IE belonging to the imperative part of a message has 
presence requirement M. An IE belonging to the non-imperative part of a message may have presence requirement "M." 

C ("Conditional") means that: 

1) Inclusion of the IE by the sender depends on conditions specified in the relevant protocol specification; 

2) There are conditions for the receiver to expect that the IE is present and/or conditions for the receiver to expect 
that the IE is not present. These conditions depend only on the message itself, and not on the state in which the 
message was received; they are known as static conditions; 

3) The receiver detecting that the IE is not present, when sufficient static conditions are fulfilled for its presence, 
shall diagnose a "missing conditional IE" error; 

4) The receiver detecting that the IE is present, when sufficient static conditions are fulfilled for its non-presence, 
shall diagnose an "unexpected conditional IE" error. 

Only IEs belonging to the non-imperative part of a message may have presence requirement "C." 

O ("Optional") means that the receiver shall never diagnose a "missing mandatory IE" error, a "missing conditional IE" 
error, or an "unexpected conditional IE" error because it detects that the IE is present or that the IE is not present. (There 
may, however, be conditions depending on the states, resources, etc. of the receiver to diagnose other errors.) Only IEs 
belonging to the non-imperative part of a message may have presence requirement "O". 
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1 1 .5 Handling of Superfluous Information 

All equipment should be able to ignore any extra information present in a standard L3 message, which is not required 
for the proper operation of that equipment. For example, a User Terminal may ignore the calling party BCD number if 
that number is of no interest to the User Terminal when a SETUP message is received. 

1 1 .5.1 Information Elements that are Unnecessary in a Message 

The relevant protocol specification may define certain IEs to be unnecessary in a standard L3 message. A protocol 
entity detecting an unnecessary IE in a received standard L3 message shall ignore the contents of that IE for treating the 
message. It is not obliged to check whether the contents of the IE are syntactically correct. 
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